Storage application performance matching

ABSTRACT

Input/output (I/O) activity in the multiple tier storage system is monitored to collect statistical information. The statistical information is recurrently transformed into an exponential moving average (EMA) of the I/O activity having a predefined smoothing factor. Data portions in the multiple tier storage system are sorted into buckets of varying temperatures corresponding to the EMA. At least one data migration plan is recurrently generated for matching the sorted data portions to at least one of an available plurality of storage device classes. One data portion sorted into a higher temperature bucket is matched with a higher performance storage device class of the available plurality of storage device classes than another data portion sorted into a lower temperature bucket.

The present application is a Continuation of U.S. patent applicationSer. No. 12/700,964, filed on Feb. 5, 2010.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to computers, and moreparticularly to a method, system, and computer program product forstorage application performance matching in multiple tier computingstorage environments.

2. Description of the Related Art

Computers and computer systems are found in a variety of settings intoday's society. Computing environments and networks may be found athome, at work, at school, in government, and in other settings.Computing environments increasingly store data in one or more storageenvironments, which in many cases are remote from the local interfacepresented to a user.

These computing storage environments may use many storage devices suchas disk drives, often working in concert, to store, retrieve, and updatea large body of data, which may then be provided to a host computerrequesting or sending the data. In some cases, a number of data storagesubsystems are collectively managed as a single data storage system.These subsystems may be managed by host “sysplex” (system complex)configurations that combine several processing units or clusters ofprocessing units. In this way, multi-tiered/multi-system computingenvironments, often including a variety of types of storage devices, maybe used to organize and process large quantities of data.

SUMMARY OF THE INVENTION

Because a variety of interconnected devices and systems may be used tomanage a particular body of data, it is beneficial to present to theuser an organization of logically organized storage units (such asvolumes) to which the user may assign storage. As a result, the userdoes not need the specific knowledge of the underlying physical storagedevice allocations to such logical units. Currently, a user of such“virtualized” multi-tiered computing environments must first, beforestorage activity on a particular storage unit takes place, configure theunit, such as a logical unit number (LUN), as part of a storage class(e.g., high/low latency or high/low capacity) by anticipating theworkload of an owning application.

The user, however, is generally unaware of application and storageperformance requirements previous to full system configuration and use,and further, is unaware how to dynamically optimize such storage units,for example, if new storage applications are used on an existing storageconfiguration. As a result, a need exists for a mechanism whereby theuser is ensured accurate assignment of storage units into particularstorage classes, and moreover, dynamic optimization of suchconfigurations in the event of changes to the computing environment.

In view of the foregoing, various embodiments for matching storageapplication performance in a multiple tier storage system are disclosed.In one embodiment, by way of example only, a method for matching storageapplication performance in a multiple tier storage system is disclosed.Input/output (I/O) activity in the multiple tier storage system ismonitored to collect statistical information. The statisticalinformation is transformed into an exponential moving average (EMA) ofthe I/O activity having a predefined smoothing factor. Data portions inthe multiple tier storage system are sorted into buckets of varyingtemperatures corresponding to the EMA. At least one data migration planis recurrently generated for matching the sorted data portions to atleast one of an available plurality of storage device classes. One dataportion sorted into a higher temperature bucket is matched with a higherperformance storage device class of the available plurality of storagedevice classes than another data portion sorted into a lower temperaturebucket.

In addition to the foregoing exemplary embodiment, various system andcomputer program embodiments are provided and supply related advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

In order that the advantages of the invention will be readilyunderstood, a more particular description of the invention brieflydescribed above will be rendered by reference to specific embodimentsthat are illustrated in the appended drawings. Understanding that thesedrawings depict only typical embodiments of the invention and are nottherefore to be considered to be limiting of its scope, the inventionwill be described and explained with additional specificity and detailthrough the use of the accompanying drawings, in which:

FIG. 1 is a block diagram illustrating an exemplary multi-tiered datastorage computing environment which may implement aspects of the presentinvention;

FIG. 2 is a block diagram of various blocks of functionality provided byaspects of the present invention;

FIG. 3A is a block diagram of an illustration of transformingstatistical I/O data into exponential moving average (EMA) informationfor the statistical data;

FIG. 3B is a block diagram of an exemplary process of temperaturesorting EMA information for the various storage units first depicted inFIG. 3A;

FIG. 4A is a block diagram of an exemplary sorting process of EMA andlatency information;

FIG. 4B pictorially illustrates the sorting process first depicted inFIG. 4A of a number of storage extents temperature sorted into variousextent buckets according to the present invention;

FIG. 5 is a block diagram of an exemplary process of initializing,calculating, and generating a data migration plan;

FIG. 6 is a flow chart diagram of an exemplary execution of a datamigration plan; and

FIG. 7 is a block diagram of an exemplary order of storage allocationtransactions pursuant to a generated data migration plan.

DETAILED DESCRIPTION OF THE DRAWINGS

As one of ordinary skill in the art will appreciate, a variety ofdiffering storage units are typically used in a particular situation.For example, solid state drives (SSD) typically have a much lowerlatency than a hard disk drive (HDD), but may also have a correspondinglower capacity. Further, tape devices may have an even higher latencythan HDD devices, but may have the greatest storage capacity (or lowestcost per unit of storage). The differences between storage unitsclassified into these exemplary classes (i.e., SSD, HDD, SATA, tape,etc.) are significant.

It is not uncommon that as the size of a body of stored data grows, theutilization efficiency of the data volume decreases. In other words, atany given time, only a small portion of the data is accessed actively,the small portion being subproportional to the data's size. Aspreviously described, the user may not originally ascertain the correctstorage configuration (e.g., the appropriate storage units in theappropriate classes) to match the capabilities of the storage systemwith the intended application workload. Moreover, the user may not havethe knowledge to apply configuration changes to existing storage unitsto accommodate changes in workload or physical configurations (e.g.,additional devices).

To address the various issues previously described, the illustratedembodiments below provide mechanisms for matching storage applicationperformance with a variety of storage units organized into variousstorage classes. In addition, the illustrated embodiments provide fordynamic matching functionality, in that a user is able to applyconfiguration changes in the storage units to better accommodate changesin workload or physical configurations. Inherent in the motivationbehind various aspects of the present invention are the variousadvantages and disadvantages provided by the storage classes. Forexample, it is beneficial for application-affiliated data having thehighest I/O activity to be associated with storage units having thelowest latency to improve performance. Similarly, it is beneficial forother data having lower I/O activity to be associated with storage unitshaving a higher latency but perhaps lower cost.

As a result, by implementation of various aspects of the presentinvention, a user may realize a multiple-tier storage system thatimproves, for example, return on investment through optimal andintelligent use of differing storage tier characteristics. This may beaccomplished, in one embodiment, by use of fine grain data placement andnon-disruptive data migration based on the I/O activities in differingregions of the storage, and by taking advantage of characteristics ofthe various storage classes, such as use of SSD for higher input/outputoperations per second (IOPS) and lower latency characteristics, and useof devices such as HDD and tape for higher capacity storage.

The illustrated embodiments dynamically identify new “hot spots” and“cold spots” in the storage system according to a changing applicationworkload. Storage system performance is monitored to adapt a fine grain(i.e., small unit of data based) data placement mechanism to anappropriate storage device class. Based on I/O statistics collected fromsuch storage system monitoring, a fine grain, non-disruptive storagemigration plan is generated, and later, executed. Accordingly, pursuantto this functionality, a user need not configure a storage unit (such asa LUN) to the appropriate device class prior to executing an owningapplication. Moreover, the storage system is capable of dynamicallyadjusting the fine grain data placement according to a changing workloadfrom one or more owning applications, or in response to a configurationchange within the storage system.

In the following description, reference is made to the accompanyingdrawings which form a part hereof and which illustrate severalembodiments of the present invention. It is understood that otherembodiments may be utilized and structural and operational changes maybe made without departing from the scope of the present invention. FIG.1 illustrates a computing storage environment in which aspects of theinvention may be implemented. A plurality of host systems 2 a, b . . . ntransmit Input/Output (I/O) requests to one or more storage volumes 28,30, and 32 through a storage controller 6 which manages access to thestorage volumes 28, 30, and 32. In certain implementations, the storagevolumes may be physically comprised of a plurality of hard disk drivesorganized as Just a Bunch of disks (JBOD), a RAID array, Direct AccessStorage Devices (DASD), SSD, tape devices, etc.

A number of virtual volumes 22, 24, and 26 are presented to the hostsystems 2 a, b . . . n in lieu of presenting a number of physical orlogical volumes (often which may be physically configured in a complexrelationship). The host systems 2 a, b . . . n may communicate with thestorage controller 6 over a network 8, such as the Internet, a StorageArea Network (SAN), an Intranet, Local Area Network (LAN), Wide AreaNetwork (WAN), etc., using multiple communication protocols such asTCP/IP, Fibre Channel, Ethernet, etc. at different layers in a protocolstack.

The storage controller 6 includes a processor 10 executing code 12 toperform storage controller operations. The storage controller 6 furtherincludes a cache 14 and non-volatile storage unit 16, such as a batterybacked-up memory device. The storage controller 6 stores in cache 14data updates received from the hosts 2 a, b . . . n to write to thevirtual storage volumes 22, 24, and 26 (and thereby to volumes 28, 30,and 32) as well as data read from the volumes 28, 30, and 32 to returnto the hosts 2 a, b . . . n. When operating in Fast Write mode, dataupdates received from the hosts 2 a, b . . . n are copied to both cache14 and the NVS 16. End status is returned to the host 2 a, b . . . nsending the data update after the update is copied to both the cache 14and NVS 16.

FIG. 1, as one of ordinary skill in the art will appreciate, mayillustrate a portion of a larger, multi-system/multi-cluster storageenvironment having a number of interrelated components such as thepreviously illustrated storage controller 6. As previously indicated,while virtual volumes 22, 24, and 26 are presented to the user via thehost systems 2 a, b . . . n, the underlying physical configuration maytake many possible forms. For example, a number of interrelated storagedevices in various classes, such as SSD, SATA, HDD, tape, etc. maycomprise the storage volumes 28, 30, and 32 depending on a particularconfiguration.

Various components of the storage environment, such as processor 10, maybe adapted to implement aspects of the present invention and followingclaimed subject matter. For example, a storage management module 18 mayoperate in conjunction with processor 10 to perform variousfunctionality to be further described, such as monitoring I/O activity,transforming the I/O activity to an analyzable representation, creationof a data migration plan, and finally, execution of this plan. One ofordinary skill in the art will appreciate that other various dataprocessing and memory components may be implemented to realize theseaspects, and may be operational on the storage controller 6, orelsewhere. Storage management module 18 may further comprise a varietyof additional modules as will be further described to implement variousportions of functionality. For example, in one embodiment, the storagemanager module 18 may further comprise an I/O monitor module, dataplacement advisor module, data migration planner module, and datamigrator module as will be further described with reference to FIG. 2,following.

Turning now to FIG. 2, a block diagram of various functional aspects ofthe present invention are depicted as an exemplary flow. As previouslydescribed, I/O performance statistics of a logical, non-overlapping unitof storage are collected and recorded for every I/O operation. Suchlogical non-overlapping unit of storage may be a logical block device, asubdivision within a logical block device, a file, a subdivision withina logical file, a database table space, or database objects. In everyfixed duration, a set of performance data is shapshot. This performancedata may include such information as an I/O access pattern (e.g.,read/write counters, I/O counters, etc.) and cumulative latencycharacteristics 52, as well as a cache miss count, total datatransferred, and an average I/O size, for example. In one embodiment, anI/O monitor module 54 gathers such performance data. In today'smulti-system storage environments, one of ordinary skill in the art willappreciate that the number of logical storage units monitored may rangein the millions to hundreds of millions of units.

Following the collection of the aforementioned performance data, the“raw” performance data is digested and transformed to performance trenddata kept in the form of moving averages (including predefined smoothingfactors corresponding to each moving average), as will be furtherdescribed. The digested form helps to reduce metadata storage and allowsfor significantly more historical data to be retained. In addition, thetransformed data may be used to determine which of short-term orlong-term performance demands of the storage system should be firstaddressed.

In one exemplary embodiment, a data placement advisor module 58 collects300 data samples in one day, and collects 2000-2100 data samples in oneweek (e.g., the long, short inputs 56 as shown). The collection of acertain number of samples per a predefined interval may vary accordingto a particular implementation, as one of ordinary skill in the art willappreciate. In this context, 300 samples may be used to generate shortterm moving average data, and 2000 samples may be used to generate longterm moving average data. This transformation is further described inFIGS. 3A and 3B, following, where in FIG. 3A, for example, a collection80 of short and long term moving average transformations (e.g., 84, 92)of performance data are represented for a number of storage units. Inone example, the I/O activity of storage unit 82 is transformed into ashort term moving average value 86 and a long term moving average value88. Similarly, I/O activity of storage unit 90 is transformed into shortterm moving average value 94 and a long term moving average value 96.

The moving averages may be used in sorting and ranking the performanceof different logical units of storage. By doing so, data placementanalysis will identify “hot spot” and “cold spot” candidates ofdifferent storage tiers, classes or pools. Hot spot candidates may bethought of as logical units of storage where an owning applicationdemands a higher I/O performance capacity, while cold spot candidatesare the opposite. These candidates may be sorted and are passed to thenext phase to evaluate cost-benefit considerations of possible dataplacement and/or data migration. In the example sorted lists 98 depictedin FIG. 3B, following, two sorted lists are illustrated (such as devices82 and 90).

Turning next to FIGS. 4A and 4B, the functionality of datatransformation into exponential moving averages and subsequenttemperature sorting are further depicted in block diagram form in oneexemplary embodiment. In FIG. 4A, an exemplary set oftemperature-specific classifications 100 is depicted. In the depictedexample, a “hot” set of I/O statistics is classified in category 102.Category 102 features data having higher calculated EMA values based onI/O counters, and higher EMA values based on cumulative latency. Inother words the data represented in classification 102 has high shortterm and long term EMA values. A less hot set of I/O statistics isclassified in category 104, where data having lower I/O counter-basedEMA values, yet higher cumulative latency-based EMA values is placed. Astill less hot set of I/O statistics is classified in category 106,where data having higher I/O counter-based EMA values yet lowercumulative latency-based EMA values is placed. Finally, that data havinglow I/O counter-based EMA values and lower cumulative latency-based EMAvalues is placed into category 108 as the coldest classification. EachEMA transformation of relevant I/O statistics is characterized by apredetermined smoothing factor corresponding to the particular EMA. Oneof ordinary skill in the art will appreciate that the exemplarytemperature-specific classifications as shown in FIG. 4A may be tailoredfor migration between various storage devices, and may vary for aparticular implementation.

An exemplary depiction of such temperature sorting (based on the fourtemperature classifications seen previously in FIG. 4A) is shown in FIG.4B, following. As shown, a number of extents, or contiguous portions ofdata blocks, are placed in an extent map 112. Pursuant to temperaturesorted bucketing 114, each of the extents in the extent map 112 aresorted into one of a number of buckets corresponding to a particulartemperature. As shown, the hottest extents are sorted into bucket 116,while less hot extents are sorted into bucket 118, 120, and so on, untilbucket 122 is filled with the remaining extents from the extent map 112.As one of ordinary skill in the art will appreciate, a varying number ofbuckets may be designated corresponding to certain specific temperaturecharacteristics.

Returning to FIG. 2, the temperature sorting functionality exemplifiedin FIG. 4B is represented, where an analytics engine 70 (in the depictedembodiment) is responsible for transforming the extent-based rawperformance statistics 66 into extent-based EMA performance statistics(including a predefined smoothing factor corresponding to each EMA),which are then sorted into hot and cold candidates 68 as previouslydescribed.

As a following step in the depicted flow of FIG. 2, a data migrationplanner module 62 performs data migration planning functionality as willbe now described, for example, by taking considerations of deviceperformance, classification, cost(s) of data migration, systemperformance, and utilization 60 into account. These considerations areutilized to generate a logical device migration plan 72 as will befurther described. The logical device migration plan 72 providesguidance to storage system management (be it user controlled orimplemented pursuant to a storage management application). The storagesystem then may take steps to execute data migration in accordance withsome or all of the recommendations of the logical device migration plan,with a non-disruptive view.

FIG. 5, following, illustrates various blocks of functionality forperforming data migration planning 130 in an exemplary flow. As abeginning step, each of the hot and cold candidates 132 (which again canvary according to the number of buckets initialized) are placed into aflow control filter module 134 for processing. The data migrationplanner (DMP) module 140 then takes various factors/considerations intoaccount, such as data originating from various system monitoringmodules. These modules are depicted as system performance monitor, hotspot region monitor, cost model, and past plan execution monitor modules136, 138, 142, and 144, and provide various statistical information tothe DMP module 140. While an amount or priority of the statisticalinformation may vary, the depicted embodiment shows information stemmingfrom monitoring of system performance, determinations of regions ofvarying temperatures, cost model(s), and historical information asinputs to the DMP module 140.

DMP module 140 analyzes the various inputs as previously described,providing them to a plan generator module 146 for generation of amigration plan 148 as will be further described. In one embodiment, themigration plan may include any or all of the steps 150 depicted in FIG.5, such as promoting data currently associated with one or more HDDdevices 154 to regions of one or more SSD devices 152, demoting datacurrently associated with one or more SSD devices 156 to be associatedwith one or more HDD devices 158, and finally, swapping data currentlyassociated with one or more SSD devices 160 with data currentlyassociated with one or more HDD devices 162.

FIG. 6, following, is a flow chart diagram of exemplary data migrationplanning 170 that may be implemented according to aspects of the presentinvention. During such data migration planning, the DMP module uses (inthe illustrated embodiment) the following decision logic to determinehow to generate a migration plan to move data among and between afastest tier (tier 0) and a number of slower tiers (tier n). To startsuch planning (step 172), the DMP module first determines if there isfree available space in tier 0 (step 174). If so, the method 170 movesto step 190, where the method prepares for data promotion pursuant tothe data migration plan. If no, the method 170 then moves to step 176,where the method begins to make further determinations as to whether todemote or swap data as will be further described.

Returning to step 190, the method 170 determines if there are any hotdata candidates in the temperature-sorted moving average list in tier n.The head of the list represents the hottest data within thecorresponding tier n. Pursuant to this determination, the hot candidatesare tested to determine whether their performance trending is increasing(step 192). To make this determination, the method 170 compares theshort term moving averages to the long term moving averages. If theshort term moving averages is larger or equal to the long term movingaverages, then the particular hot candidate is determined to be on an“up” trend, and the method 170 moves to either step 194 or step 196.Otherwise, the candidate is not determined to be on an up trend, and themethod 170 exits the current considerations for the particular candidateand returns to step 190 to look for additional hot candidates having anup trend.

Returning to steps 194 and 196, the method 174 (depending on variousdeterminations of the DMP), begins to prepare to generate a promotingdata migration plan for the hot candidate on tier n. For example, theDMP may determine whether the migration cost of this particular hotcandidate is justified by determining whether the projected performancegain of the hot data candidate resulting on the tier 0 will be largerthan the cost migration. The projected performance can be determined byusing the current performance profile and modeled if the same workloadapplied to the tier 0. Hence the projected performance gain is equal tocurrent performance minus the project performance. The cost of migrationcan be calculated a priori in terms of I/O count and total latency.

If the projected performance gain is a net gain pursuant to theaforementioned cost/benefit comparison (step 186), the promoting datamigration plan is generated for the selected hot candidate (step 188).If the data suggest pursuant to the cost benefit comparison in block 186that such a net gain is not clearly satisfied, then the hot candidatemay be a better candidate for swap functionality according to block 196,and again pursuant to these determinations, the swapping data migrationplan output is generated for the selected candidate (again, step 188).

Returning to step 176, the method 170 determines if any cold datacandidates are found in the temperature-sorted moving average list intier 0. In one embodiment, the tail of the list represents the coldestdata within the corresponding tier 0. The cold data candidate will betested as to whether the performance trending is down. To determinewhether the performance trend is down for the selected cold candidate,the method 170 again compares the short term moving averages to the longmoving averages (step 178). If the short term moving average is smalleror equal to the long term moving average, then the candidate is trendingdown, and the method 178 moves to step 184. Otherwise, the candidate isnot on the down trend, and the method 170 exits analysis for theselected candidate and returns to step 176 to identify additional coldcandidates with a down trend. If no additional cold candidates arefound, the method 170 ends (step 180).

Returning to step 182, a determination is made whether any hot datacandidates are found in the temperature-sorted moving average list intier n. In one embodiment, the head of the list represents the hottestdata within the corresponding tier n. This candidate will be tested asto whether performance trending is up (again, step 192). Here again, todetermine whether the performance trending is increasing, the short termmoving average is compared against the long term moving average. If theshort term moving average is larger or equal to the long term movingaverage, the candidate is on an up trend, and the method moves to eitherstep 194 and 196 as previously described. Alternatively, the candidate(again now for tier n) is not on an increasing trend, and the method 170exists the current analysis and returns back to step 190 to look foradditional lower-tiered data candidates.

If no additional hot candidates are found for the particular tier, thenthe method 170 moves from step 182 to step 192, where it prepares togenerate a swapping data migration plan for the hot data candidate ontier n, and the cold data candidate on tier 0. Pursuant to thisdetermination the method 170 again conducts cost/benefit comparisons inblock 186 described previously, such as determinations as to whether theswap migration cost of the selected hot data candidate and cold datacandidate is justified. This may be performed by calculating whether theprojected performance gain of the hot data candidate resulting on thetier 0 minus the projected performance loss of cold data candidateresult on the tier n will be larger than the cost of migration. Theprojected performance can be determined by using the current performanceprofile and modeled if the same workload applied to the tier 0 or tiern. Hence the projected performance gain is equal to current performanceminus the project performance. To obtain comparable units, theperformance gain is multiplied by a time, such as the expected time intier 0. The cost of migration can be calculated a priori in terms of I/Ocount and total latency.

Following generation of various migration plans for selected hot/coldcandidates, a number of exemplary steps may be taken to implementpromoting, swapping, and/or demoting functionality as previouslydescribed. For example, pursuant to implementing a promoting datamigration plan, a free storage resource may first be allocated in thetarget tier. The source of the migration is then read to a data buffer.Next, the buffer is written to the free storage resource. Finally, theresource containing the source of data migration is deallocated.

Similar steps may be taken in implementing a swapping data migration.First, a free resource is allocated in a source hot tier. Next, thesource of the cold candidate is read to a data buffer. The buffer iswritten to the free resource. A vacant resource of the cold candidate isreserved. The source of the hot candidate is read to the data buffer,the buffer is then written to the vacant resource, and finally, theresource originally containing the hot candidate is deallocated.

Here again, similar steps may be taken in a demoting data migration. Afree resource is first allocated, and the source of migration is read toa data buffer. The buffer is written to the free resource, and theresource originally containing the source of migration is deallocated.As one of ordinary skill in the art will appreciate, each of the varioussteps described above may be varied according to a particularimplementation. Furthermore, the steps may be repeated for each of thehot and cold candidates on varying tiers until none are remaining.

In one embodiment, a data migrator (DM) module executes the recommendmigration plan. The DM provides necessary serialization and resourceallocation support to manage the data migration integrity. In thissense, the migration plan is a suggestion, where no resource isallocated or no serialization of broader system activities isconsidered. The DM may be adapted to throttle the amount of datamigration bandwidth, and observe system limitations, as the migrationplan is executed.

Turning finally to FIG. 7, a block diagram of an exemplary order ofstorage allocation transactions pursuant to a generated data migrationplan is depicted. FIG. 7 illustrates an exemplary execution order formigrating each of a number of data migrations organized in a transactiongroup (column 202). Each of the transaction groups corresponds to alogical storage unit (column 204), a logical dataset (column 206), asource device class (column 208), and a destination device class (column210). Arrow 212 indicates an execution order of the listed datamigrations.

As will be appreciated by one of ordinary skill in the art, aspects ofthe present invention may be embodied as a system, method or computerprogram product. Accordingly, aspects of the present invention may takethe form of an entirely hardware embodiment, an entirely softwareembodiment (including firmware, resident software, micro-code, etc.) oran embodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module,” “process” or“system.” Furthermore, aspects of the present invention may take theform of a computer program product embodied in one or more computerreadable medium(s) having computer readable program code embodiedthereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wired, optical fiber cable, RF, etc., or any suitable combination of theforegoing. Computer program code for carrying out operations for aspectsof the present invention may be written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Java, Smalltalk, C++ or the like and conventionalprocedural programming languages, such as the “C” programming languageor similar programming languages. The program code may execute entirelyon the user's computer, partly on the user's computer, or entirely onthe remote computer or server. In the last scenario, the remote computermay be connected to the user's computer through any type of network,including a local area network (LAN) or a wide area network (WAN), orthe connection may be made to an external computer (for example, throughthe Internet using an Internet Service Provider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks. The computer program instructions may also beloaded onto a computer, other programmable data processing apparatus, orother devices to cause a series of operational steps to be performed onthe computer, other programmable apparatus or other devices to produce acomputer implemented process such that the instructions which execute onthe computer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the above figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

While one or more embodiments of the present invention have beenillustrated in detail, one of ordinary skill in the art will appreciatethat modifications and adaptations to those embodiments may be madewithout departing from the scope of the present invention as set forthin the following claims.

1. A method for matching storage application performance in a multipletier storage system by a processor device, comprising: monitoringinput/output (I/O) activity in the multiple tier storage system tocollect statistical information; recurrently transforming thestatistical information of the I/O activity using an exponential movingaverage (EMA) having a predefined smoothing factor to obtain an EMAvalue; sorting data portions in the multiple tier storage system intobuckets of varying temperatures corresponding to the EMA value;recurrently generating at least one data migration plan for matching thesorted data portions to at least one of an available plurality ofstorage device classes, wherein one data portion sorted into a highertemperature bucket having higher EMA values is matched with a higherperformance storage device class of the available plurality of storagedevice classes than another data portion sorted into a lower temperaturebucket having lower EMA values, wherein the plurality of storage deviceclasses includes a fastest tier 0 and a number of slower tiers n;identifying a hot candidate in one or more of the number of slower tiersn; determining whether the hot candidate has an up trend; and promotingthe hot candidate to a faster tier.
 2. The method of claim 1, whereinthe sorting data portions includes sorting extents of the multiple tierstorage system into the buckets of varying temperatures corresponding tothe EMA value.
 3. The method of claim 1, wherein the monitoring I/Oactivity in the multiple tier storage system is repeated for each of aplurality of predefined smoothing factors having decreasing values togenerate at least a shorter and a longer EMA of the I/O activity.
 4. Themethod of claim 3, further including performing one of: pursuant todetecting that the longer EMA of the I/O activity is smaller than theshorter EMA of the I/O activity, adjusting the at least one datamigration plan to consider a current up trend change of the I/Oactivity, and pursuant to detecting that the longer EMA is larger thanthe shorter EMA of the I/O activity, adjusting the at least one datamigration plan to consider current down trend change of the I/Oactivity.
 5. The method of claim 1, wherein the generating at least onedata migration plan includes performing at least one of: promoting theone data portion sorted into the higher temperature bucket from one ormore storage devices in a hard disk drive (HDD) class to one or morestorage devices in a solid state drive (SSD) class, demoting the anotherdata portion sorted into the lower temperature bucket from the one ormore storage devices in the SSD class to the one or more devices in theHDD class, and swapping the another data portion sorted into the lowertemperature bucket in the one or more storage devices in the SSD classwith the one data portion sorted into the higher temperature bucket inthe one or more storage devices in the HDD class.
 6. The method of claim1, further including allocating the at least one of the availableplurality of storage device classes according to the generated at leastone data migration plan, wherein pursuant to the allocating the at leastone of the available plurality of storage device classes, a datamigration bandwidth is throttled so as not to disrupt overallperformance of the multiple tier storage system.
 7. The method of claim1, wherein the monitoring the I/O activity in the multiple tier storageto collect the statistical information includes collecting at least oneof: an I/O read count, an I/O write count, a cumulative latency, a cachemiss count, a total data transferred, and an average I/O size.
 8. Themethod of claim 1, wherein the promoting includes generating a promotingdata migration plan for the hot candidate.
 9. The method of claim 8,wherein the generating includes determining whether a projectedperformance gain of the hot candidate resulting on the fastest tier 0will be larger than a migration cost, wherein the projected performancegain is equal to a current performance minus a projected performance andthe migration cost is calculated a priori in terms of I/O count andtotal latency.
 10. The method of claim 9, wherein generating includes:generating the migration plan, if the projected performance gain is anet gain; and generating a swapping data migration plan, if theprojected performance is not a net gain.
 11. A method for matchingstorage application performance in a multiple tier storage system by aprocessor device, comprising: monitoring input/output (I/O) activity inthe multiple tier storage system to collect statistical information;recurrently transforming the statistical information of the I/O activityusing an exponential moving average (EMA) having a predefined smoothingfactor to obtain an EMA value; sorting data portions in the multipletier storage system into buckets of varying temperatures correspondingto the EMA value; recurrently generating at least one data migrationplan for matching the sorted data portions to at least one of anavailable plurality of storage device classes, wherein one data portionsorted into a higher temperature bucket having higher EMA values ismatched with a higher performance storage device class of the availableplurality of storage device classes than another data portion sortedinto a lower temperature bucket having lower EMA values, wherein theplurality of storage device classes includes a fastest tier 0 and anumber of slower tiers n; identifying a cold candidate in the fastesttier 0; determining whether the cold candidate has a down trend; anddemoting the cold candidate from the faster tier 0 to one of the numberof slower tiers n.
 12. The method of claim 11, wherein identifyingincludes identifying the cold candidate from a temperature-sorted movingaverage list in fastest tier 0, wherein a tail of the temperature-sortedmoving average list represents coldest data within the fastest tier 0.13. The method of claim 11, wherein the monitoring I/O activity in themultiple tier storage system is repeated for each of a plurality ofpredefined smoothing factors having decreasing values to generate atleast a shorter and a longer EMA of the I/O activity.
 14. The method ofclaim 13, further including performing one of: pursuant to detectingthat the longer EMA of the I/O activity is smaller than the shorter EMAof the I/O activity, adjusting the at least one data migration plan toconsider a current up trend change of the I/O activity, and pursuant todetecting that the longer EMA is larger than the shorter EMA of the I/Oactivity, adjusting the at least one data migration plan to considercurrent down trend change of the I/O activity.